Reading the codebase first

Every contract starts with pressure to produce something visible in week one. It is usually the wrong instinct and I have stopped agreeing to it.

What the code already decided

A codebase is a record of decisions, most of them undocumented and some of them load-bearing. The odd abstraction in the middle of the data layer is not always someone being clever; often it is the shape of a constraint nobody wrote down — a client who needs two currencies, a regulator who needs an audit trail.

Ship in week one and you will route around those without knowing they exist. Then you will spend week six discovering why the thing you routed around was there.

Read the tests and the git log

Tests tell you what the team was afraid of. The git log tells you where the pain was — the file touched four hundred times is where the requirements are still moving, and it is the last place you want to introduce a new abstraction in your first fortnight.

The visible cost

The honest downside is that a week of reading looks like nothing from outside, and on a short contract that is a real problem for the person paying. I now say it plainly at the start: the first week produces a written account of how the system works and what I think is risky in it. That is a deliverable, it just is not a screenshot.

Every time I have skipped it to look productive, I have paid for the week later at a worse exchange rate.